Test equipment, and in particular cable network test equipment, frequently requires a user to choose between functionally distinct tests. The tests are selected in dependence upon a problem being investigated. Typically, the tests are selected from a list-type menu structure, an icon-based menu structure, or a combination of the two menu structures. The user must be able to know which tests and test modes to employ in each particular case. Multiple tests are often required to investigate most problems, such as a poor quality of digital reception, for example. To assist the user, shortcuts can be provided in a graphical user interface of the test equipment. The shortcuts take the user directly from one mode to another without having to return to the main menu.
Referring to FIG. 1, a flow chart of a prior-art method of investigating a network problem is shown. At a step 101, a user, such as a field test technician, selects a test to be run. The test is selected based on the technician's knowledge of which tests need to be run to investigate a particular problem, as shown schematically with an arrow 102. At a step 103, the tests are run by the test device. At a step 104, the test results are obtained, typically in form of a table or a graph on a display unit of the test device. At a step 105, the results are analyzed by the technician to find a root cause of the problem. This step also requires a specific knowledge by the technician, as is shown by an arrow 106. At a step 107, the technician selects further action or actions to be taken to further investigate the problem, and the process continues as illustrated with dots 109 until the root cause of the problem is found. The step 107 of selecting further actions to be taken also requires knowledge 108 by the technician of all tests available to the test device and the appropriate circumstances under which the tests are to be run.
One drawback with the traditional approach illustrated in FIG. 1 is that it requires the field service technicians using the test equipment to know in detail the circumstances under which each test is to be run. Considering a large number of tests that can be run to troubleshoot a particular problem, and considering a significant extent of problems that might occur, this requirement is difficult to meet in practice. Furthermore, new equipment is being developed and added to a typical cable network to expand services delivered to clients. New equipment and associated new services can only be deployed if an equipment update is adequately supported by a growing testing and troubleshooting capability, which requires new tests to be added on ongoing basis. Maintaining an adequate up-to-date training of the technical personnel in such rapidly growing environment represents a formidable challenge.
One known solution to simplify the testing procedure is to program the test equipment to run predetermined successions of tests using a scripted succession of test commands. In this mode, which is sometimes called “autotest” mode, the testing equipment consecutively runs all the measurements listed in the script, typically on multiple information channels. At the end of the measurements cycle, the test equipment generates a table showing test results. For example, channel power readings can be displayed, for all channels present, so that the user can check whether channels of interest have sufficient power to be reliably detected. Many other tests, such as modulation error ratio (MER), bit error ratio (BER), carrier-to-noise ratio (CNR), quadrature amplitude modulation (QAM) ingress, etc., are also performed on channel-by-channel basis.
While scripted “autotest” measurements provide an advantage of standardized testing done by field service technicians, allowing comprehensive and standardized data logging, the sheer amount of information presented to the technician at the end of the “autotest” represents a difficulty to the technician, whose task is to quickly determine the root cause of the problem. To be able to understand and navigate in vast amounts of data generated by the “autotest”, the technician must not only understand the basics of network operation, but also be familiar with data processing and have strong analytical skills. Therefore, introduction of “autotest” does not reduce the amount of training required. In essence, it simply expands the required training into another area.
The prior art is lacking a solution that would allow a user to quickly analyze a particular problem without requiring ongoing, extensive, and time-consuming on-the-job training. Accordingly, it is a goal of the present invention to provide a solution that reduces the amount of training required, while streamlining and standardizing the testing process.